這篇整理 AWS 的成本管理工具：查看費用組成的 Cost Explorer、找出浪費的 Trusted Advisor 與 Compute Optimizer、以承諾換折扣的 Savings Plans，以及提早發現費用異常的 AWS Budgets 與 Cost Anomaly Detection。

這些工具有固定的使用順序：先看見費用的組成，再找出浪費，接著調整購買方式，最後持續監控。順序不能反過來：先買了承諾再縮小規格，買下的承諾會用不完。

以下以一次實際的情況為例：某公司收到的帳單比上個月多了 30%，沒有人知道錢多花在哪裡。

🔍 看見錢花在哪：Cost Explorer

用途：把帳單拆開，找出費用來自哪個服務、哪個帳號、哪個專案。

Cost Explorer 把帳單資料畫成圖表，可以查看過去 13 個月的費用，並預測未來的費用。它的用處在於切分：

依服務切分後，增加最多的是 EC2 與資料傳輸。接著想依專案切分，卻發現選單中沒有 project 這個 tag：資源上的 tag 不會自動出現在帳單中，要在 Billing 主控台把它啟用為 cost allocation tag，Cost Explorer 才能依它分組。這是考題常見的陷阱：資源都已經加上 tag，報表卻看不到。

使用 AWS Organizations 時，所有帳號的費用合併成一張帳單（consolidated billing）：用量合併計算階梯價格，Savings Plans 與 RI 的折扣也能在帳號之間共用。需要比 Cost Explorer 更細的資料時，Cost and Usage Report 把每小時、每個資源的用量與費用送到 S3，供 Athena 等工具分析。

知道錢花在 EC2 和資料傳輸之後，下一步是找出其中哪些是浪費。

🧹 找出浪費：Trusted Advisor 與 Compute Optimizer

用途：找出還在計費、卻沒有在工作的資源。

常見的浪費有幾種：

找出這些資源的兩個工具：

開發環境下班時間仍在執行的問題，可以用 EventBridge 排程或 Instance Scheduler 在固定時間停止與啟動 instance。

EC2 的浪費處理完，還剩下資料傳輸那一塊。

🌐 資料傳輸費用

用途：了解哪些傳輸路徑會收費，從架構上避開不必要的費用。

資料傳輸費用不顯眼，卻常在帳單上佔很大一部分，也是考題常出現的成本陷阱。費用取決於四件事：用私有還是公有 IP、跨不跨 AZ 或 Region、往不往網際網路、經不經過 NAT gateway：

依這些規則，常見的省錢設計：

• 同一個 VPC 內的機器互相通訊時，用私有 IP，不用公有 IP
• private subnet 存取 S3、DynamoDB 時，用 gateway endpoint 避開 NAT gateway
• 大量內容傳給網際網路使用者時，經由 CloudFront 傳送：從 AWS 上的源站傳到 CloudFront 不收費，CloudFront 傳給使用者的單價也較低，再加上快取減少回源
• 跨 AZ 的流量要付費，但多 AZ 部署是為了可用性，不應為了省傳輸費而放棄。只有在大量、頻繁通訊而且不影響可用性的情況下，才考慮放在同一個 AZ

浪費清掉之後，剩下的才是真正需要的用量，這時才適合調整購買方式。

💳 調整購買方式：Savings Plans、RI 與 Spot

用途：對長期穩定的用量做出承諾，換取比 On-Demand 低的價格。

選擇方式是把用量拆成幾層：

全天候都會用到的基本用量  → Savings Plans 或 RI
  ├ 未來可能換 instance 系列、Region，或有 Fargate、Lambda → Compute Savings Plans
  └ 確定長期用同一個系列                             → EC2 Instance Savings Plans（折扣較高）
尖峰時增加的用量         → On-Demand
可以被中斷的工作         → Spot

Cost Explorer 會依過去的用量建議該承諾多少金額，購買後再以兩份報告追蹤：涵蓋率是多少用量有被折扣涵蓋，使用率是買下的承諾有多少被用到；使用率低代表買太多。

Savings Plans 只給折扣，不保留容量。需要確保某個 AZ 一定有容量時，用 zonal RI 或 On-Demand Capacity Reservation。

這次的費用增加處理完了。剩下的問題是：下次怎麼在月中就發現，而不是等到月底收到帳單。

🚨 讓下次提早發現：AWS Budgets 與 Cost Anomaly Detection

用途：費用超出預期時自動通知，甚至自動採取行動，不必等到月底。

兩個服務都會發出通知，判斷的方式不同：

AWS Budgets 是自己設定金額，超過就通知：

Budgets 依帳單資料判斷，資料每天更新數次，不是即時的。

AWS Cost Anomaly Detection 以機器學習學習每個服務、帳號平常的費用型態，偵測到偏離的情況就通知，不需要設定門檻，費用型態隨季節變化時也會自動調整。例如 Lambda 的程式錯誤造成大量重複呼叫，費用還沒超過整個月的預算，但已經和平常明顯不同，就會被偵測出來。通知可以是偵測到就立即透過 SNS 送出的 individual alert，或以 email 寄送的每日、每週摘要。

摘要：用 Cost Explorer 找出費用來源，用 Trusted Advisor 與 Compute Optimizer 清掉閒置、縮小規格，剩下的穩定用量再購買 Savings Plans；最後以 Budgets 控制總金額，以 Cost Anomaly Detection 及早發現異常增加。

🧠 AI 出題

問題 1

某公司在單一 AWS 帳號中執行 6 個專案，所有資源都已依規定加上 project tag，例如 project=checkout。財務部門想在 Cost Explorer 中依專案查看每月的費用並分攤給各部門，但依 tag 分組時，Cost Explorer 的選項中找不到 project 這個 tag。

哪一個做法能最快（as quickly as possible）讓財務部門依專案查看費用？

• A. 在 Billing 主控台把 project 啟用為 cost allocation tag，之後在 Cost Explorer 中以這個 tag 分組查看費用
• B. 建立 AWS Cost Categories，以 project tag 的值定義 6 個專案的分類規則，再在 Cost Explorer 中以這個分類來查看費用
• C. 為 6 個專案各建立一個新帳號並把資源搬過去，再以 Organizations 的 consolidated billing 依帳號查看各專案的費用
• D. 建立 Cost and Usage Report 匯出到 S3，再用 Amazon Athena 依報表中的資源 tag 欄位彙總各專案的費用

問題 2

某公司全年都有穩定的運算用量：一部分在 EC2 上，目前以 m5 與 c5 系列為主，但預計明年改用 Graviton 的 m7g 系列，並可能把部分服務搬到另一個 Region；另一部分是 Amazon ECS on Fargate 與 AWS Lambda。公司願意承諾 3 年的用量以換取折扣。

哪一個購買方式最符合成本效益（MOST cost-effective），又能涵蓋這些變化？

• A. 購買 m5 與 c5 系列的 3 年期 Standard Reserved Instances，並在改用 m7g 系列時把它們轉賣到 Reserved Instance Marketplace
• B. 購買 m5 與 c5 系列的 3 年期 EC2 Instance Savings Plans，並在 Fargate 與 Lambda 的部分繼續以 On-Demand 價格計費
• C. 購買 3 年期的 Convertible Reserved Instances，在改用 m7g 系列或換 Region 時，以兌換的方式換成新的 instance 設定
• D. 依 Cost Explorer 的建議購買 3 年期 Compute Savings Plans，以每小時固定的承諾金額涵蓋 EC2、Fargate 與 Lambda 用量

問題 3

某資料分析公司在同一個 AZ 執行一個 12 個節點的 EC2 運算叢集，節點之間每天交換數十 TB 的資料。為了方便設定，每個節點都綁定了 Elastic IP，叢集的程式以這些 Elastic IP 互相連線。帳單顯示每月有大量的區域內資料傳輸費用，但叢集的運算量並沒有增加。

哪一個方案能以最低的成本解決這個問題？

• A. 把節點移入 cluster placement group 並啟用 enhanced networking，提高節點之間的網路頻寬並降低延遲
• B. 把 12 個節點移到同一個 subnet，並保留 Elastic IP，讓節點之間的流量不再經過 subnet 之間的路由
• C. 修改叢集的設定，讓節點之間改以私有 IP 位址互相連線，並把不再需要對外連線的 Elastic IP 釋放
• D. 為叢集所在的 VPC 建立 interface endpoint，讓節點之間的流量改經 AWS PrivateLink 傳送以避開公有網路

問題 4

某公司以 AWS Organizations 管理 30 個帳號，並已訂閱 Business Support。財務長要求在一個月內完成兩件事：依實際的 CPU 與記憶體使用率找出規格過大的 EC2 並取得建議的新規格；找出所有帳號中閒置的 load balancer 與未關聯的 Elastic IP。所有 EC2 都已安裝 CloudWatch agent 送出記憶體使用率，團隊希望盡量使用現成的工具。

解決方案架構師應該採取哪兩項做法？（選擇兩項）

• A. 在 Organizations 的管理帳號啟用 AWS Compute Optimizer 並涵蓋所有成員帳號，依它的建議調整 EC2 的規格
• B. 使用 Trusted Advisor 的成本優化檢查並以組織檢視彙整所有帳號，找出閒置的 load balancer 與未關聯的 Elastic IP
• C. 啟用 AWS Cost Anomaly Detection 並為每個帳號建立 monitor，在偵測到費用異常時以 email 通知各帳號的負責人逐一處理
• D. 撰寫 Lambda 函式每天讀取所有帳號的 CloudWatch metric，依自訂門檻判斷規格過大的 EC2 並產生建議清單
• E. 在每個帳號建立 AWS Budgets 的成本預算，超過上個月費用的 80% 時通知財務部門人工檢查各帳號的資源用量

問題 5

某新創公司上個月的 AWS 帳單比平常多了 4 倍，月底才發現原因是 Lambda 函式的錯誤造成大量重複呼叫。公司有十多個服務，費用會隨季節和促銷活動波動，難以為每個服務設定固定的門檻。公司要求之後類似的意外要在一天內被發現並通知工程團隊。

哪一個方案的維運負擔最低（LEAST operational overhead）？

• A. 為每個服務建立 AWS Budgets 的成本預算並設定固定門檻，每季依前一季的費用重新調整一次門檻與通知對象
• B. 啟用 AWS Cost Anomaly Detection 建立依服務分析的 monitor，並以 individual alert 透過 SNS 通知
• C. 在 CloudWatch 對 EstimatedCharges metric 建立 alarm，總費用超過上個月同期的金額時透過 SNS 通知工程團隊
• D. 指派一位工程師每天早上登入 Cost Explorer 查看前一天各服務的費用，發現異常時再通知相關團隊處理

💡 解答

1. A

資源上的 tag 不會自動出現在帳單資料中，必須在 Billing 主控台把 project 啟用為 cost allocation tag，Cost Explorer 才能依它分組。資源已經全部加上 tag，啟用之後就能依專案查看費用；需要啟用前的資料時，還可以申請回填過去的 tag 資料。這是最直接、最快的做法。

B 是最有誘惑力的干擾項：Cost Categories 確實能依 tag 把費用歸到不同的專案，但它的 tag 規則只能使用「已啟用的 cost allocation tag」；project 還沒啟用，規則根本選不到這個 tag，最後還是要先完成 A。C 確實能依帳號切分費用，但要把 6 個專案的資源搬到新帳號，工作量最大、耗時最久。D 一樣卡在同一個前提：Cost and Usage Report 只會包含已啟用為 cost allocation tag 的 tag 欄位，project 沒有啟用就不會出現在報表裡；就算啟用了，再架 S3 與 Athena 的查詢也比直接用 Cost Explorer 慢得多。

2. D

Compute Savings Plans 承諾的是每小時的使用金額，不綁定 instance 系列、大小或 Region，還涵蓋 Fargate 與 Lambda。改用 m7g 系列、把服務搬到另一個 Region，折扣都會自動套用，三種運算用量也都在同一個承諾內，是在這些變化下成本最低的選擇。

A 的 Standard RI 綁定特定的 instance 設定，改系列後就用不到，轉賣到 Marketplace 不一定賣得掉，也賣不到原價；Fargate 與 Lambda 也不在涵蓋範圍內。B 的 EC2 Instance Savings Plans 限定一個 Region 的一個 instance 系列，改用 m7g 或換 Region 時折扣就不再適用，Fargate 與 Lambda 也沒有折扣。C 的 Convertible RI 能兌換成其他系列，但只適用於 EC2，Fargate 與 Lambda 仍以 On-Demand 計費，折扣也低於 Compute Savings Plans 能涵蓋的範圍。

3. C

同一個 AZ 內以私有 IP 傳輸資料不收費；以公有 IP 或 Elastic IP 傳輸時，即使兩台機器在同一個 AZ，也以跨 AZ 的費率收費。叢集改用私有 IP 互相連線，數十 TB 的傳輸費用就消失了；不再需要的 Elastic IP 釋放後，也不會繼續產生公有 IPv4 的費用。

A 的 cluster placement group 與 enhanced networking 提升的是頻寬與延遲，計費方式取決於使用的 IP 類型，流量仍然經由 Elastic IP 傳輸，費用不變。B 誤以為費用來自跨 subnet：同一個 AZ 內不同 subnet 之間以私有 IP 傳輸本來就不收費，這筆費用來自經由 Elastic IP 傳輸，節點仍以 Elastic IP 互連，搬到同一個 subnet 也不會改變。D 是誤解：interface endpoint 用於存取 AWS 服務或 PrivateLink 提供的服務，不是用來承載 EC2 節點之間的流量，還會增加 endpoint 的費用。

4. A、B

Compute Optimizer 依 CloudWatch 的使用率資料分析 EC2，給出規格過大的 instance 與建議的新規格；在管理帳號啟用並涵蓋所有成員帳號後，30 個帳號的建議都能集中查看（記憶體使用率來自已安裝的 CloudWatch agent）。Trusted Advisor 的成本優化檢查包含閒置的 load balancer 與未關聯的 Elastic IP，公司已有 Business Support 可以使用完整的檢查，組織檢視能彙整所有帳號的結果。兩項分別滿足兩個要求。

C 的 Cost Anomaly Detection 偵測的是費用突然偏離平常的情況，長期存在的閒置資源與規格過大不會被當成異常。D 可以做到第一項，但要自己撰寫判斷邏輯並維護，不符合「盡量使用現成工具」，也沒有處理閒置資源的部分。E 的 Budgets 只在費用超過門檻時通知，無法指出是哪些資源閒置或規格過大。

5. B

Cost Anomaly Detection 以機器學習學習每個服務平常的費用型態，包括季節與促銷的波動，不需要為每個服務設定門檻；設定 individual alert subscription，偵測到異常就立即透過 SNS 通知工程團隊（daily／weekly summary 只能寄 email，不能送 SNS）。像 Lambda 重複呼叫造成的費用暴增，會被當成這個服務的異常而及早發現。

A 能發出通知，但要為十多個服務各自設定固定門檻，還要每季調整，題目已經說明費用波動大、難以設定門檻，維運負擔最高。C 的 EstimatedCharges 是整個帳號的累計總費用，無法分辨是哪個服務異常；而且月初累計金額還很低，單一服務的暴增可能要過好幾天才會讓總額超過門檻。D 靠人工每天檢查，能做到一天內發現，但完全依賴人力，維運負擔明顯高於自動偵測。